Release 10.1A: OpenEdge Getting Started:
Object-oriented Programming

Using the CLASS construct

The first compilable line in a class file must define the class using the CLASS statement. The CLASS statement is only valid in a file with the .cls extension. The name of the class file must always match the class name of the type defined in the file. The last compilable line in a class is the END CLASS statement, which must terminate the main block of the class.

This is the syntax for a defining a class:

Syntax

CLASS type-name [ INHERITS super-type-name ]   [ IMPLEMENTS interface-type-name [ , interface-type-name ] ... ]   [ USE-WIDGET-POOL ] [ FINAL ] :     [ data-member ... ]     [ event-handler ... ]     [ udf-prototype ... ]     [ constructor ]     [ method ... ]     [ destructor ] END [ CLASS ] .

Element descriptions for this syntax diagram follow:

type-name
super-type-name
interface-type-name

A character string that identifies the type name for the following classes or interfaces referenced in the CLASS statement:

The class that the specified CLASS statement defines (type-name).
Any super class inherited by the defined class (super-type-name).
Each specified interface that the defined class implements (interface-type-name).

All type name references in the CLASS statement have the following syntax:

Syntax

[package.]class-name

package

A character string that specifies a period-separated list of components that, along with class-name, uniquely identify the class, super class, or interface among all classes and interfaces. The components are based on a valid directory pathname relative to PROPATH, where each component maps to a directory level in the path and each forward or backward slash separator in the path is replaced with a period (.). If specified, the relative pathname represented by package specifies the location of the class file that contains the class or interface definition. Any package specification must remain constant between compile time and run time.

Note: Do not place a class file in a directory whose name contains a period (.) character. Progress interprets the component after the period as another directory level and will therefore not find the referenced class file.
class-name

A character string that specifies a class or interface name. This name must match the name of a class file (excluding its .cls or .r extension) that contains the definition for the defined class, specified super class, or specified interface. This class file must be located in the relative path represented by package, if specified. The class-name must begin with an alphabetic character and it cannot contain a period. This name thus represents the unqualified name of the defined class, specified super class, or specified interface. Do not specify a class name using a Progress reserved keyword or built-in Progress data type name, such as INTEGER.

If package or class-name contains embedded spaces, you must enclose the entire type name specification in quotes.

For example, a class with the type name topdir.subdir.SomeClass must be found, at compile-time, as the source file SomeClass.cls, in the directory topdir/subdir relative to the PROPATH. If the class is compiled and saved, its r-code must be found at run time in the file SomeClass.r and in the same directory path, topdir/subdir, relative to the PROPATH.

Note: The requirement to maintain a constant relative path between compile time and run time applies only to class files (not to procedure files).

INHERITS super-type-name

The INHERITS option identifies a super class that this class is inherits from. Logically the super class's non private members can be thought of as if they were part of the current class definition. The super class can be a class that in turn inherits from another class. When a class is defined using the INHERITS phrase, the class being defined is referred to as a subclass.

The super-type-name is a character string that must identify the type name for the super class using this previously-defined syntax for type-name:

Syntax

[package.]class-name

Based on this information, Progress must be able to locate the specified super class file (either the source file or the r-code file) in order to compile or run the user-defined class. Also, the specified super class cannot be defined as FINAL.

IMPLEMENTS interface-type-name [ , interface-type-name ] ... ]

The IMPLEMENTS option identifies one or more interfaces. The current class must implement all of the methods defined in each interface listed.

The interface-type-name is a character string that must identify the type name for the interface using this previously-defined syntax for type-name:

Syntax

[package.]class-name

Based on this information, Progress must be able to locate this interface class file (either the source file or the r-code file) in order to compile or run the user-defined class.

USE-WIDGET-POOL

Directs Progress to create an unnamed widget pool scoped to the current class. When specified, Progress creates those dynamic widgets and objects that you instantiate both in this class and in a widget pool, and places them within this class unnamed widget-pool by default. Otherwise, Progress creates class- and widget-pool-instantiated dynamic widget and object instances in the session unnamed widget-pool. Progress deletes the associated class unnamed widget-pool when the instance of this class is deleted. For more information on using widget pools with classes, see the "Using widget pools" section.

FINAL

The FINAL option means this class cannot be inherited. That is, it cannot be specified as a super class for the INHERITS option of another class definition.

data-member

A class can define zero or more data members of the class. For more information, see the "Defining data members within a class" section.

event-handler

A class can define zero or more ON statement-based event handlers for a class. Each ON statement specifies a response to a specific set of Progress events, mostly from interactions with Progress GUI objects. For more information, see the "Handling events" section.

udf-prototype

If you invoke a user-defined function in a procedure object handle from within the method of a class, you must provide the function prototype and a handle to the running external procedure where the user-defined function is defined. You must also provide the function prototype with the IN SUPER option if the user-defined function is defined in a super procedure for the session. This is the same prototype and handle reference that you must provide in any procedure that references an external user-defined function. For more information, see the reference entry for the FUNCTION statement in OpenEdge Development: Progress 4GL Reference .

constructor

A class can define a constructor for the class. For more information, see the "Defining the class constructor" section.

method

A class can define zero or more methods for the class. For more information, see the "Defining methods within a class" section.

destructor

A class can define a destructor for the class. For more information, see the "Defining the class destructor" section.

You can terminate a CLASS statement with either a period (.) or a colon (:). The data-member, event-handler, udf-prototype, constructor, method, and destructor specifications can occur in any order.

The following sample shows a definition for a class:

CLASS acme.myObjs.Common.CommonObj: ... END CLASS.

The following sample shows a definition for a class that inherits from the previous class, its super class:

CLASS acme.myObjs.CustObj INHERITS acme.myObjs.Common.CommonObj: ... END CLASS.

Following sections make reference to and build on this sample class definition (by reference to “the sample class”). This class and the associated class and interface definitions in this chapter represent a partial implementation of sample classes fully presented in a later chapter of this manual. For more information, see the "Comparing constructs in classes and procedures" section.

Class type name examples

The type-name, super-type-name, and interface-type-name specified in the CLASS and INTERFACE statement syntax (see the "Using the CLASS construct" section and the "Using the INTERFACE construct" section) must evaluate at compile time to a class file. The specified name must be enclosed in quotes if the name contains embedded spaces. If the name does not contain embedded spaces, the class type name can be specified without quotes. A character variable or character expression can never be used to identify the class file.

Valid and invalid class type name references

These are examples of valid class type name references:

CLASS acme.myObjs.CustObj. CLASS "Program Files.myObjs.CustObj". CLASS {&myClassName}.

In this previous example, the reference to {&myClassName} is a preprocessor directive.

These are examples of invalid class type names:

CLASS myLocalVariable. CLASS "Program Files" + "." + "myObjs.CustObj".

In this previous example, myLocalVariable is a character variable.

These invalid examples illustrate one of the key aspects of using classes, namely strong typing. The compiler would be unable to know the run-time value of myLocalVariable, and thus would not be able to verify whether the class type name matches its physical location or whether references to the class from other classes were valid. For the same reason, the second example of an invalid class type name shows that the compiler cannot assemble a name even from multiple character literals that are concatenated using the "+" operator.

However, you can combine a preprocessor name with other parts of a literal class type name, as in the following example, because this combination is evaluated and combined into a single literal string at compile time:

CLASS {&AccountingNamespace}myClassName:

Note that on some operating systems, a period (.) is a valid character in a directory name. Because Progress uses the same character as the delimiter within the package and between the package and the class type name, you may not place class files in a subdirectory whose name contains a period. Progress would not be able to differentiate the period in the directory name from the period acting as a delimiter in the class type name, and would not find the referenced class file.

Using type names to locate classes on the PROPATH

The examples in Table 2–1 show three class statements that identify three different user-defined classes. The examples assume that PROPATH contains a single directory. That directory contains two subdirectories named accounting and inventory.

Table 2–1: Class type names and PROPATH

The file that specifies the following class type name. . .	Must be found in. . .
CLASS Customer:	A directory in PROPATH.
CLASS accounting.Customer:	The accounting subdirectory relative to PROPATH.
CLASS inventory.Customer:	The inventory subdirectory relative to PROPATH.

These files must be able to be located on PROPATH at both compile time and run time. However, the value of PROPATH can change between compile time and run time.